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Abstract 
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1. Introduction 


Route Flap Damping (RFD) was first proposed (see [RIPE178] and 
[RFC2439]) and subsequently implemented to reduce BGP churn in 
routers. Unfortunately, RFD was found to severely penalize sites for 
being well connected because topological richness amplifies the 
number of update messages exchanged, see [MAO2002]. Subsequently, 
many operators turned RFD off; see [RIPE378]. Based on the 
measurements of [PELSSER2011], [RIPE580] now recommends that RFD is 
usable with some changes to the parameters. Based on the same 
measurements, this document recommends adjusting a few RFD 
algorithmic constants and limits. The result is damping of a non- 
trivial amount of long-term churn without penalizing well-behaved 
prefixes’ normal convergence process. 


Very few prefixes are responsible for a large amount of the BGP 
messages received by a router; see [HUSTON2006] and [PELSSER2011]. 
For example, the measurements in [PELSSER2011] showed that only 3% of 
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the prefixes were responsible for 36% percent of the BGP messages at 
a router with real feeds from a Tier-1 provider and an Internet 
Exchange Point during a one-week experiment. Only these very 
frequently flapping prefixes should be damped. The values 
recommended in Section 6 achieve this. Thus, RFD can be enabled, and 
some churn reduced. 


The goal is to, with absolutely minimal change, ameliorate the danger 
of current RFD implementations and use. It is not a panacea, nor is 
it a deep and thorough approach to flap reduction. 


1.1. Suggested Reading 


It is assumed that the reader understands BGP [RFC4271] and Route 
Flap Damping [RFC2439]. This work is based on the measurements in 
the paper [PELSSER2011]. A survey of Japanese operators’ use of RFD 
and their desires is reported in [RFD-SURVEY]. 


2. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 
be interpreted as described in RFC 2119 [RFC2119] only when they 
appear in all upper case. They may also appear in lower or mixed 
case as English words, without normative meaning. 


3. RFD Parameters 
The following RFD parameters are common to all implementations. Some 
may be tuned by the operator, some not. There is currently no 


consensus on a single set of default values. 


to - 5-5 A +---------- +------- +--------- + 
| Parameter | Tunable? | Cisco | Juniper | 
toa 55 AE A +---------- +------- +--------- + 
| Withdrawal | No | 1,000 | 1,000 | 
| Re-Advertisement | No | o | 1,000 | 
| Attribute Change | No | 500 | 500 | 
| Suppress Threshold | Yes | 2,000 | 3,000 | 
Half-Life (min.) Yes | 15 | 15 | 
Reuse Threshold Yes 750 750 
| Max Suppress Time (min.) | Yes | 60 | 60 | 
toa e n Eae E EEE +---------- +-------— S a e + 


Note: Values without units specified are dimensionless constants. 


Table 1: Default RFD Parameters of Juniper and Cisco 
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4. 


I3 


Suppress Threshold versus Churn 


By turning RFD back on with the values recommended in Section 6, 
churn is reduced. Moreover, with these values, prefixes going 
through normal convergence are generally not damped. 


[PELSSER2011] estimates that, with a suppress threshold of 6,000, the 
BGP update rate is reduced by 19% compared to a situation without RFD 
enabled. [PELSSER2011] studies the number of prefixes damped over a 
week between September 29, 2010 and October 6, 2010. With this 6,000 
suppress threshold, 90% fewer prefixes are damped compared to use of 
a 2,000 threshold. That is, far fewer well-behaved prefixes are 
damped. 


Setting the suppress threshold to 12,000 leads to very few damped 
prefixes (0.22% of the prefixes were damped with a threshold of 
12,000 in the experiments in [PELSSER2011], yielding an average 
hourly update reduction of 11% compared to not using RFD). 


+--------------- +------------- 4+-------------- +---------------------- + 
| Suppress | Damped | % of Table | Update Rate (one- | 
| Threshold | Prefixes | Damped | hour bins) | 
$HsSsSsssessce- +esSSSsssesSse paretet n SoS -assee eases + 
| 2,000 | 43,342 | 13.16% | 53143) | 
| 4,000 | 11253 3.42% | 74.16% | 
| 6,000 | 4,352 | 12325... 81.03% | 
| 8,000 | 2,104 | 0.64% | 84.85% | 
10,000 1,286 0.39% 87.12% 
12,000 720 0.22% 88.74% 
| 14,000 | 504 | 0.15% | 89.97% | 
| 16,000 | 353 | OSTIS || 91.01% | 
| 18,000 | 311 | 0.09% | 91.88% | 
| 20,000 | 261 | 0.08% | 92.69% | 
+--------------- +------------- 4+-------------- +---------------------- + 


Note: the current default Suppress Threshold (2,000) is overly 
agressive. 


Table 2: Damped Prefixes vs. Churn, from [PELSSER2011] 
Maximum Penalty 
It is important to understand that the parameters shown in Table 1 


and the implementation’s sampling rate impose an upper bound on the 
penalty value, which we can call the ’computed maximum penalty’. 
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In addition, BGP implementations have an internal constant, which we 
will call the ’maximum penalty’, and the current computed penalty may 
not exceed it. 


6. Recommendations 
Use of the following values is recommended: 


Router Maximum Penalty: The internal constant for the maximum 
penalty value MUST be raised to at least 50,000. 


Default Configurable Parameters: In order not to break existing 
operational configurations, existing BGP implementations, 
including the examples in Table 1, SHOULD NOT change their default 
values. 


Minimum Suppress Threshold: Operators that want damping that is much 
less destructive than the current damping, but still somewhat 
aggressive, SHOULD configure the Suppress Threshold to no less 
than 6,000. 


Conservative Suppress Threshold: Conservative operators SHOULD 
configure the Suppress Threshold to no less than 12,000. 


Calculate But Do Not Damp: Implementations MAY have a test mode 
where the operator can see the results of a particular 
configuration without actually damping any prefixes. This will 
allow for fine-tuning of parameters without losing reachability. 


7. Security Considerations 


It is well known that an attacker can generate false flapping to 
cause a victim’s prefix(es) to be damped. 


As the recommendations merely change parameters to more conservative 
values, there should be no increase in risk. In fact, the parameter 
change to more conservative values should slightly mitigate the 
false-flap attack. 
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